Columbia Kermit/kermit.zip/newsgroups/misc.19950726-19950929/[e-mail]_Mon Sep 4 02:31:17 1995.msg

Internet Message Format | 2020-01-01 | 3KB

Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA04379
  (5.65c+CU/IDA-1.4.4/HLK for <[e-mail]>); Sun, 3 Sep 1995 22:31:19 -0400
Received: by apakabar.cc.columbia.edu id AA00538
  (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Sun, 3 Sep 1995 22:31:18 -0400
Path: news.columbia.edu!konichiwa.cc.columbia.edu!chaiklin
From: [e-mail] (Seth Chaiklin)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: MS-KERMIT 3.14 hanging on idle TCP/IP connection?
Date: 4 Sep 1995 02:31:17 GMT
Organization: Columbia University
Lines: 66
Message-Id: <42dodl$[e-mail]>
References: <42d2u9$[e-mail]> <[e-mail]>
Nntp-Posting-Host: konichiwa.cc.columbia.edu
Apparently-To: [e-mail]


Joe Doupnik <[e-mail]> wrote:
>    Did you have a chance to look at the ARP cache on the Linux machine?
>I've heard rumors (I don't use Linux) that it times out and can yield just
>the effects noted. You might try pinging MSK from the Linux end as one way
>of correcting its ARP cache.

You are definitely on the right track (and thanks for the fast response!).

I tried an experiment.  I let the MSK machine sit idle while
connected to the Linux machine, and after 10 minutes (while true;
do date; arp -a; sleep 60; done), I discovered that the Linux arp
cache loses the HW address of the ethernet card, at which point,
of course, the MSK machine appears to be frozen.

I tried pinging the MSK machine from the Linux machine, but it
does not respond.  However, if I hand-entered the HW address for
the MSK machine, then deleted this entry from the arp cache, and
then added it again, I could reestablish input/output being shown
on the MSK machine, and everything seems to work as it should.

>    You should also double check memory management on the PC to avoid
>clobbering the Ethernet adapter (presumed, you didn't say), and also to
>seek out and destroy IRQ & port conflicts. Remember to leave video memory,
>segments A000-BFFF, to the video system. These matters are discussed in
>the release notes. Do worry about PC screen savers and green machine
>power-downs too.

Thanks for these additional suggestions.  Good to know for the future,
but the machine where I was having the problems is:

An elder XT with 640K.  There is no memory to manage, and
definitely not green!  There are no screen savers.  There are
keyboard and codepage drivers installed, as well as a Cyrnwr packet
driver, otherwise no other TSRs. The monochrome monitor has a
hercules-compatible card.  There is a single serial port IRQ4, and
the ethernet adapter is IRQ3.  The ethernet adaptor is a 3c501.

However, I tried the same experiment (with the same results) with
a 486 VGA monitor machine and a 3c509 ethernet card, so I
suspect the problem is not with MSK nor with the PC-hardware.

However, there is still one part that bothers me:  Why would MSK crash
the PC in the process of exiting from MSK?  This happens even if I
logout from the Linux machine (because it is still possible to
issue commands, even if the arp cache has lost the ethernet address,
and if it they are not shown on the monitor).  That doesn't seem
right. (It doesn't crash if I reload the arp cache.)

Meanwhile, thanks very much for the insightful suggestion.

Cheers,
  Seth Chaiklin